REMARKS 



Claims 1-5, 7-10 and 12 are pending. Claim 1 has been amended to remove the word 
"table" from the phrase "said identifier look-up table element" at line 1 1 thereof. 

On page 2 of the Office Action, claims 1-5 and 7-10 are rejected under 35 USC § 1 12 as 
being indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. In particular, the Office Action states that claim 1 recites the 
limitation "said identifier look-up table element" in line 1 1 and that there is insufficient 
antecedent basis for this limitation in the claim. Applicants are traversing this rejection. In this 
regard and as indicated above, the phrase "said identifier look-up table element" has been 
corrected by removal of the word "table". 

On pages 2-4 of the Office Action, claims 1-5, 7-10 and 12 are currently rejected under 
35 USC § 103(a) as being unpatentable over US 6,963,586 (hereinafter referred to as 
"Henriksson et al.") in view of US 6,5 15,993 (hereinafter referred to as "Williams et al.") and 
US 5,732,074 (hereinafter referred to as "Spaur et al."). Applicants are traversing this rejection. 

The application presently contains two independent claims, namely claims 1 and 12. 
Below, Applicants explain that Henriksson et al. in combination with Williams et al. and Spaur 
et al. does not teach all of the elements of claims 1 and 12. 

As stated at Col. 1, lines 7-12 of Henriksson et al., this document relates to a reception 
packet processor and a protocol processor. Henriksson et al. attempts to address a number of 
technical problems, but most notable is the technical problem of evolving protocols. Henriksson 
et al. therefore attempt to find a solution that will cope with evolving protocols. While 
Henriksson et al. is entitled "Method and Apparatus for General-Purpose Packet Reception 
Processing", the "general purpose" aspect of Henriksson et al. is nevertheless highly targeted to 
packet reception processes that accommodate the transmission of larger data volumes (for 
example, an ATM packet of more than 1500 bytes) that are transmitted as packets (column 6, 
lines 9-18). The packet reception process is also based upon the premise that the location, 
encoding and usage of header information and data fields are already defined within a standard. 
As details of this document have already been described in Applicant' s previous Amendment, for 
the sake of conciseness the description of Henriksson et al. will not be repeated herein. 

However, page 3, line 12 - page 4, line 15 of the Office Action draws a number of 
parallels between the features of claim 1 and the disclosure of Henriksson et al. Applicant will 
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now discuss a number of the features of claim 1 that the Office Action alleges are taught by 
Henriksson et al. 

Turning to claim 1, claim 1 recites an automotive information controller for an 
automotive communication system having at least one communication bus having an information 
unit with an identifier portion and a data portion corresponding to said identifier portion, said 
information controller comprising: 

• an identifier look-up element for sending a predetermined program selector to a signal 
handler upon determination that the identifier portion of a received information unit 
corresponds to a predetermined identifier associated with the predetermined program 
selector; wherein 

• the program selector defines an operation to be performed on the data portion by the 
signal handler; and 

• said identifier look-up element further comprises a look-up table for storing a list of 
identifiers, 

• said identifier look-up table element searching the look-up table in order to find said 
predetermined identifier and said predetermined program selector corresponding to said 
identifier portion. 

Page 3, lines 19-22 of the Office Action states that identifier look-up element (20) of 
claim 1 corresponds to the field extraction unit 22 and the compare unit 24 of Henriksson et al. 
However, it is respectfully pointed out that neither the field extraction unit 22 nor the compare 
unit 24 possess look-up functionality . As explained in col. 11, lines 13-15, the multiple field 
extraction unit 22 can extract at least one data word from, or field from outputs of the dynamic 
buffer [10]. The compare unit 24 is used to compare a plurality of parameters output by the 
parameter code book (PCB) 54 (see col. 12, lines 59-62). As explained at col. 7, lines 16-20, the 
PCB 54 is a look-up table , the PCB 54 does not perform the act of looking-up, it is the repository 
that is the subject of a look up function. Also, the PCB 54 is not part of the compare unit 24. 
The actual look-up functionality is performed by the instruction decoder 44 as explained at col. 
12, lines 17-21. Hence, the assertion in the Office Action that the field extraction unit 22 
operating in combination with the compare unit 24 constitutes the identifier look-up element of 
claim 1 is technically incorrect. 
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Claim 1 also recites that the identifier look-up element for sending a predetermined 
program selector to a signal handler . Unfortunately, the Office Action does not identify which 
element of Henriksson et al. corresponds to the signal handler. In this respect, Applicant 
respectfully submits that Henriksson et al. does not disclose the signal handler. 

Page 3, line 22 (final line) - Page 4, line 5 concerns the recital: 

"for sending a predetermined program selector to a signal handler upon determination 
that the identifier portion of a received information unit corresponds to a predetermined 
identifier associated with the predetermined program selector" 

The Office Action states that "based upon the comparing unit result an instruction is 
selected from the first look-up table, col. 4, lines 36-44". The reasoning here is understood by the 
Applicant. However, it is respectfully submitted that the reasoning is erroneous, because firstly 
the field extraction unit 22 and the compare unit 24 do not send the predetermined program 
selector. The field extraction unit 22 and the compare unit 24 generate a set of flags. The flags 
are not predetermined and depend upon a number of factors including a vector from the PCB 54 
and fields of the header. Secondly, it is not clear as to the identity of the signal handler. Also, the 
Office Action does not identify the stage of the processing as described in Henriksson et al. that 
relates the above feature of claim 1, e.g. in respect of the "first header information" or the 
"second header information". Hence, it is also submitted that the argumentation relating to this 
feature of claim 1 is incomplete and hence improperly formulated. 

In relation to the phrase "for storing a list of identifiers", page 4, lines 8-9 of the Office 
Action points out that col. 7, lines 32-33 of Henriksson et al. discloses that " the look-up table 
stores addresses as a key to provide the corresponding instruction". Col. 7, lines 31-35 refers to 
the program look-up table 42 having "an address as input and provides an instruction as output" 
and the PCB 54 containing "several vectors and takes a vector number as input and gives the 
output as a vector, with all parameters of the specified vector". Clearly, the storage of the 
addresses as explained in the passage identified in the Office Action is performed by the look-up 
table 42. However, in relation to the preceding phrase "said identifier look-up element further 
comprises a look-up table " of claim 1, page 4, lines 7 of the Office Action points to the PCB 54 
and Fig. 5 of Henriksson et al. In this respect, the Office Action is identifying different look-up 
tables from Henriksson et al. to allege that the look-up table of claim 1 is taught. The Office 
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Action is not being consistent in considering the same look-up table from Henriksson et al. when 
referring to the look-up table of claim 1 . 

Lastly, page 4, lines 10-15 of the Office Action states that, according to col. 3, lines 50- 
57, the comparing unit 24 searches and matches an address to a value in a look-up table and 
provides instructions for further processing. The Office Action therefore asserts that this passage 
from Henriksson et al. discloses the identifier look-up [table] element searching the look-up table 
in order to find said predetermined identifier and said predetermined program selector 
corresponding to said identifier portion. Unfortunately, however, the col. 3, lines 50-57 does not 
disclose what the Office Action suggests is disclosed. In this respect, col. 3, lines 50-57 explains 
that the compare unit 24 generates one or more "match flags", nothing more. From col. 12, lines 
23-29, it is very clear that compare unit 24 provides an output to the flag to address translation 
unit 52 for generation of an address. Fig. 5 clearly shows that the flag to address translation unit 
52 is part of the flag generation unit 46 and is not part of the compare unit 24. Hence, the 
compare unit 24 does not generate the address . Applicant suspects that col. 3, lines 50-57 has 
simply been misconstrued, because the passage cited is part of the summary of the invention 
relating to method steps. The references to generating an address and matching the address and 
using a matched value clearly do not relate to the compare unit 24. Furthermore, col. 12, lines 
31-38 very carefully states that an instruction from the instruction decoder 44 indicates which 
table of a plurality of tables in the CCB 50 is used. This is yet another (and different) look-up 
table to the two look-up tables mentioned above. Furthermore, this passage also explains that 
part of the information used to provide the instruction according to the protocol specification is 
sent to the next program counter calculation unit 48 from the CCB 50 based upon the address 
from the flag to address translation unit 52 and the current instruction. Hence, it can be seen that 
not even the flag generation unit 46 provides the instruction, but merely part of the information 
used to provide the instruction. 

With reference to the features of claim 1 above, the teachings of cited Henriksson et al. in 
combination with Williams et al. and Spaur et al. fail to teach: an identifier look-up element for 
sending a predetermined program selector to a signal handler , that the program selector defines 
an operation to be performed on the data portion by the signal handler, a look-up table for storing 
a list of identifiers , and the identifier look-up element searching the look-up table in order to find 
said predetermined identifier and said predetermined program selector corresponding to said 
identifier portion, as recited in Claim 1. 
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Additionally, it is respectfully submitted that the Office Action fails to establish prima 
facie obviousness for the following reasons. 

The operation code taught at col. 3, lines 11-19 of Williams et al. relates to modification 
of a data frame . The elements identified above in relation to Henriksson et al. do not relate to 
modification of data other than in respect of translating flags to addresses and the payload data 
via output 9. In this respect, col. 8, lines 15-20 of Henriksson et al. states that outputs from the 
protocol processor are payload flags to guide the memory access, data validation and processing 
of the payload and are output via output terminal 9. Hence, even if the use of an operational 
code of Williams et al. were used to modify the payload data of Henriksson et al., the process of 
replacing the payload flags currently generated by Henriksson et al. would constitute a 
substantial modification to Henriksson et al. 

Accordingly, one of skill in the art would not make such a combination in that such a 
combination would change the basic principle of operation of Henricksson et al. See MPEP 
2143.01 Subsection entitled "THE PROPOSED MODIFICATION CANNOT CHANGE THE 
PRINCIPLE OF OPERATION OF A REFERENCE". 

Spaur et al. (col. 3, lines 57-65) refers to accessing information from vehicle devices by 
use of a controller communicating with a controller area network (CAN). However, the 
controller of Spaur et al. is a very different type of controller to that of claim 1 (see col. 2, line 66 
- col. 3, line 6 of Spaur et al). The combination of the teachings of Henrisksson et al. with 
Spaur et al. will therefore require considerable modification to the controller of both Spaur et al. 
as well as Henriksson et al., because the controller of Spaur et al. is completely different to the 
controller of Henricksson et al. and is not simply a matter of "slotting" the processor of 
Henricksson et al. into the controller of Spaur et al. Indeed, the Office Action does not explain 
how such a combination can be achieved. 

Accordingly, one of skill in the art would not make such a combination in that such a 
combination would render Spaur et al. and Henricksson et al. respectively unsatisfactory for its 
intended purpose. See MPEP Section 2143.01, Subsection entitled THE PROPOSED 
MODIFICATION CANNOT RENDER THE PRIOR ART UNSATISFACTORY FOR ITS 
INTENDED PURPOSE citing In re Gordon, 733 F.2d 900 (Fed Cir. 1984). 

Also, the reasons stated in the Office Action for combining the references is insufficient 
for establishing prima facie obviousness. 
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In this respect, the reason given in the Office Action for combining the teachings of 
Henriksson et al. with Williams et al. is simply: 

". . .it would have been a person of ordinary skill to in the art to modify the program 
selector of Henriksson et al. '586 so that program selector defines an operation to be 
performed on the data portion by the signal handler, as taught by Williams et al. '586 
because it enables to select and execute the desired operation on-the-fly so that no need 
of data buffering . The motivation for doing so would have been to optimize packet 
processing" [Emphasis added] 

However, while cited Henriksson et al. has, as an objective, on-the-fly processing, the 
Office Action does not advance any evidence that Williams et al. will satisfy this requirement 
and also obviate buffering. Furthermore, these reasons appear to be taken from Henriksson et al. 
at col. 2, lines 3-5. Indeed, Henricksson et al. professes to provide on-the-fly processing and to 
obviate the need for buffering. Consequently, it is respectfully submitted that if Henricksson et 
al. meets the above needs, the skilled person would have no reason to refer to Williams et al. 

Hence, it is submitted that a sufficient reason has not been provided. Referring to MPEP 
Section 2143.01, Subsection IV entitled "Mere Statement That The Claimed Invention Is Within 
the Capabilities of One of Ordinary Skill in the Art is Not Sufficient By Itself To Establish Prima 
Facie Obviousness." should be followed, this subsection states: "Rejections on obviousness 
cannot be sustained by mere conclusionary statements; instead, there must be some articulated 
reasoning with some rational underpinning to support the legal conclusion of obviousness.'" KSR 
Int'l v. Teleflex, Inc., 550 U.S. 127, 82 USPQ2d at 1396 (2007). See also Ex parte Penhasi, 
BPAI Appeal No. 2007-2534 (December 13, 2007) ("The Examiner has not articulated a 
sufficient reason why one skilled in the art would have modified [the art] and arrived at the 
presently claimed subject matter."). It is therefore submitted that the Office Action has not 
satisfied the necessary criteria of providing a reasoning to combine Henricksson et al. with 
Williams et al. and so the rejection raised is improperly formulated. 

Furthermore, Henriksson et al. does not suggest modification thereof with the teachings 
of William et al. or Spaur et al. Similarly, Williams et al. does not suggest modification thereof 
with the teachings of Spaur et al. Indeed, it is submitted that the skilled person, reading 
Henriksson et al. or Williams et al, is not provided with a reasonable expectation of success 
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when making the combination suggested in the Office Action due to the lack of any such 
indication of suitability or desirability to make a modification. 

Hence, there is no teaching in the cited prior art suggesting the modification and the 
present application only teaches the modified apparatus. See THE TEACHING OR 
SUGGESTION TO MAKE THE CLAIMED COMBINATION AND THE REASONABLE 
EXPECTATION OF SUCCESS MUST BOTH BE FOUND IN THE PRIOR ART, NOT IN 
APPLICANT'S DISCLOSURE. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). 

In view of the reasoning provided above, Applicant submits that Henriksson et al. in 
view of Williams et al. and Spaur et al. does not render claim 1 obvious. 

Claims 2-5 and 7-10 depend from Claim 1. By virtue of this dependence, claims 2-5 and 
7-10 are also not obvious. 

Claim 12 is a method claim corresponding to the apparatus of claim 1. Consequently, the 
arguments set forth above in support of claim 1 apply equally to claim 12. As such, it is 
therefore respectfully submitted that the teachings of Henriksson et al. in combination with 
Williams et al. and Spaur et al. fail to teach: receiving the identifier portion at an identifier look- 
up element, the identifier look-up element comprises a look-up table for storing a list of 
identifiers, searching the look-up table in order to find a predetermined identifier and a 
predetermined program selector, and sending the predetermined program selector to a signal 
handler, as recited in claim 12. 

In view of the reasoning provided above, Applicant submits that Henriksson et al. in view 
of Williams et al. and Spaur et al. does not render claim 12 obvious. 

The case is believed to be in condition for allowance and notice to such effect is 
respectfully requested. If there is any issue that may be resolved, the Examiner is respectfully 
requested to telephone the undersigned. 



Respectfully submitted, 
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